1. Field of the Invention
Embodiments of the present invention relate to the field of data storage systems. More particularly, embodiments of the present invention relate generally to the automatic allocation of disks in a data storage system to provide redundant, efficient and reliable storage.
2. Related Art
Secondary data storage is an integral part of large data processing systems. A typical data storage system in the past utilized a single, expensive magnetic disk for storing large amounts of data. This single disk in general is accessed by the Central Processing Unit (CPU) through a separate Direct Memory Access (DMA) controller. The DMA controller then translates and executes the Input/Output (I/O) requests of the CPU. For single disk memory storage systems, the speed of data transfer to and from the single, large disk is much slower than the processing speed of the CPU and acts as a data processing bottleneck.
In response, redundant arrays of independent disks (RAIDs) have evolved from the single disk storage systems in order to match the speed of secondary storage access with the increasingly faster processing speeds of the CPU. To increase system throughput, the RAID architecture of secondary storage allows for the concurrent access of data from multiple disk drives.
The concept for the RAID architecture was first formalized in an article written by some members of the Department of Electrical Engineering and Computer Sciences at the University of California at Berkeley, entitled: “A Case for Redundant Arrays of Inexpensive Disks (RAID),” by D. A. Patterson, G. Gibson, and R. H. Katz, ACM SIGMOD Conference, Chicago, Ill., June 1988, hereinafter referred to as “Patterson et al.”
Typically, RAID architectures consist of one or more host interface controllers connected to several peripheral interface controllers via a high-speed data bus. Each peripheral interface controller is, in turn, connected to several individual disk drives, which provide the secondary storage for the connected hosts. Peripheral interface controllers, also referred to as array controllers herein, can be connected to the disk drives via common communication interfaces (e.g., SCSI). Generally, the speed of the data bus is greater than the speed of the interface between the disk drives and the peripheral interface controllers.
Some RAID storage systems contain spare disk drives. Storage units with additional spare disks are designed to operate continuously over a specified period of time, without requiring any repair of the unit due to failed disks. This is accomplished by carefully identifying and quantifying the components that are expected to fail during a given time period, and incorporating within the system sufficient hot-spare parts or disks. This internal spare disk architecture can automatically switch to the spare disks when a failure is encountered. Spares are incorporated so that compatible disk devices are always at hand upon a disk failure.
Prior Art FIG. 1 depicts a common implementation of a data storage system 100 containing spare disks. The data storage system is arranged in a mirrored configuration 105a & b–125a & b with three spares 130, 132 & 135. In the data storage system 100, a data volume is divided into segments called stripe units. Stripe units are mapped consecutively on a set of physical devices for parallel access purposes.
For example, data storage system 100 contains thirteen disks. Ten of the disks (e.g., disks 105a & b, 110a & b, 115a & b, 120a & b, and 125a & b) contain data and their redundancies. The remaining three disks (e.g., disks 130, 132 and 135) are spare disks.
Further, system 100 stripes its data across groups of data strips. In the redundancy group of stripe 150a, disk 105a contains strip 101a, disk 110a contains strip 102a, disk 115a contains strip 103a, disk 120a contains strip 104a and disk 125a contains strip 107a. Mirrored stripe 150b contains mirrored strips, e.g. strip 107b that mirrors 107a. 
A disadvantage of the redundant disk storage array is that it is configured by a system administrator who has the daunting task of building the system. This requires knowing every component in the system and creating the system so that it performs well, is reliable and never loses data. If a component fails and must be replaced, it becomes necessary to reconfigure the system, requiring numerous manipulations in order to have the system working again.
In order to build the system, the System Administrator needs to issue many commands, interfacing through a plethora of graphical user interface (GUI) panels to define the disks to be used and to assure that the controllers are different for mirrored disks. He has to define the areas on the disks that will be strung together to define the stripes, and keep track of the configuration. Within the configuration, disks can be mirrored, or spare portions can be spread over a group of disks, or both. If spread out over the array of disks, there are many RAID configurations, depending on how many disks in a group and the amount of redundant storage allocated. All these different configurations require complex and technical settings and parameters to be formulated by the system administrator and programmed into the system using, often times, cumbersome programming tools. All this needs to be done so as to be able to write a maximum amount of data in a minimum amount of time, efficiently and with reliability that if any piece fails, data will not be lost.
The system administrator also has to create hot spare pools in order to have sufficient spare components available to replace failed components. He has to track failures and project future failures in order to keep the spare pools sufficiently populated.